Beralih ke Produksi: Pola Pikir Pengembangan

Modul terakhir ini menghubungkan celah antara penelitian yang sukses—di mana kita mencapai akurasi tinggi dalam sebuah catatan—dan eksekusi yang andal. Pengembangan adalah proses krusial dalam mengubah model PyTorch menjadi layanan minimal, layanan mandiri yang mampu memberikan prediksi secara efisien kepada pengguna akhir dengan latensi rendah dan ketersediaan tinggi.

1. Perubahan Pola Pikir Produksi

Lingkungan eksploratif dari catatan Jupyter bersifat berbasis status dan rapuh untuk penggunaan produksi. Kita harus merefaktor kode kita dari skrip eksploratif menjadi komponen terstruktur dan modular yang sesuai untuk permintaan bersamaan, optimasi sumber daya, serta integrasi mulus ke dalam sistem yang lebih besar.

Inferensi Latensi Rendah: Mencapai waktu prediksi secara konsisten di bawah ambang batas target (misalnya, $50\text{ms}$), sangat penting untuk aplikasi waktu nyata.

Ketersediaan Tinggi: Merancang layanan agar dapat diandalkan, tanpa status, dan mampu pulih dengan cepat dari kegagalan.

Reproduktibilitas: Menjamin bahwa model dan lingkungan yang diimplementasikan (dependensi, bobot, konfigurasi) persis sama dengan hasil penelitian yang telah divalidasi.

Fokus: Layanan Model

Alih-alih mengimplementasikan seluruh skrip pelatihan, kita mengimplementasikan pembungkus layanan minimal dan mandiri. Layanan ini hanya perlu menangani tiga tugas: memuat artefak model yang dioptimalkan, menerapkan pra-pemrosesan input, dan menjalankan proses maju untuk mengembalikan prediksi.

TERMINALbash — uvicorn-service

> Ready. Click "Simulate Deployment Flow" to run.

ARTIFACT INSPECTOR Live

Simulate flow to view loaded production artifacts.

Question 1

Which feature of a Jupyter notebook makes it unsuitable for production deployment?

It primarily uses Python code

It is inherently stateful and resource-intensive

It cannot directly access the GPU

Question 2

What is the primary purpose of converting a PyTorch model to TorchScript or ONNX before deployment?

Optimization for faster C++ execution and reduced Python dependency

To prevent model theft or reverse engineering

To automatically handle input data preprocessing

Question 3

When designing a production API, when should the model weights be loaded?

Once, when the service initializes

At the start of every prediction request

When the first request to the service is received

Challenge: Defining the Minimal Service

Plan the structural requirements for a low-latency service.

You need to deploy a complex image classification model ($1\text{GB}$) that requires specialized image preprocessing. It must handle $50$ requests per second.

Step 1

To ensure high throughput and low average latency, what is the single most critical structural change needed for the Python script?

Solution:
Refactor the codebase into isolated modules (Preprocessing, Model Definition, Inference Runner) and ensure the entire process is packaged for containerization.

Step 2

What is the minimum necessary "artifact" to ship, besides the trained weights?

Solution:
The exact code/class definition used for preprocessing and the model architecture definition, serialized and coupled with the weights.